Appl. No. 09/970,724 

Amdt. Dated August 9, 2006 

Reply to Office action of July 26, 2006 

Remarks/Arguments 

In response to the Non-Compliant Notice of July 26, 2006, the Applicants have correctly 
listed claim 6. 

The Examiner is thanked for the careful review of this Application. Claims 1-20 are 
pending after entry of the present Amendment. Amendments were made to claims to correct 
typographical errors and to better define the claimed invention. The amendments do not 
introduce new matter. 

Rejections under 35 U.S.C* § 101 : 

The Office has rejected claims 1-20 of the claimed invention as being nonstatutory for 
failing to have tangible embodiments. It is respectfully submitted that claims 1-20 have 
amended claims 1-20 so as to overcome the Office's rejections. For instance, independent 
claims 1 and 13, and 8 have been amended respectively to recite a transport independent RTP 
stack to be executed by a computer system , and an RTP connector module to be executed by a 
computer system . In view of the clarifying amendments, the Applicants respectfully request 
that rejection of claims 1-20 under 35 U.S.C. § 101 be withdrawn. 

Rejections under 35 U.S.C. § 112„ First Paragraph ; 

The Office has rejected claims 1-20 under 35 U.S.C. § 1 12, first paragraph as failing to 
comply with the enablement requirement. The Office has specifically interpreted that claims 1 - 
20 are for a connector module which converts types to other types. The Office has further 
rejected claims 1-20 under 35 U.S.C. § 1 12, first paragraph based on the specification failing to 
describe any methods present in the transport-independent tasks module. Furthermore, the 
Office has rejected claims 1-20 under 35 U.S.C. § 1 12, first paragraph, as failing to comply with 
the written description requirement for containing subject matter which was not described in the 
specification. 

The Applicants respectfully traverse the Office's interpretations that the claims are "for 
a connector module which converts types to types." Rather, it is respectfully submitted that, 
among other features, the connector module of the claimed invention can adapt the RTP stack to 
any type of transport layer. Nonetheless, to clarify the claimed invention and to overcome the 
Office's rejections under 35 U.S.C. § 112, first paragraph, the Applicants have amended 
independent claims 1, 8, and 13. For instance, as amended, independent claims 1 and 13 recite 
that a new connector module is configured to be generated so as to adapt the RTP stack to a 
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second underlying transport layer having a different transport layer type . As amended, 
independent claim 8 recites that a new RTP connector module is configured to be generated for 
each underlying transport layer having a different transport layer type so as to adapt the RTP 
stack to the corresponding underlying transport layer. 

The Applicants respectfully submit that the specification, as originally filed, supports 
the Applicants' amendments. For instance, on page 14, lines 5-10, the Applicants provide: 

Thus, using the Java language, embodiments of the present invention 
can provide a default RTP connector 502 for use with a particular type of 
transport, for example, an IP-based network via UDP datagram packets. Then, 
a new RTP connector 502 can be designed as a class for use over another 
transport, such as ATM . The new ATM RTP connector class can then be 
implemented by passing the new ATM RTP connector class to an 
initialization method. [Emphasis added.] 

Furthermore, On page 10, lines 21-23, the specification provides that "the multimedia 

application 402 can be adapted to operate over another network environment by adapting the 

RTP connector of the transport independent RTP stack 404 to the new network transport 

layer." On page 11, lines 15-16, the specification further provides that "the RTP connector 502 

can be used to adapt the transport-independent RTP stack 404 to any type of transport layer." 

Furthermore, the Applicants respectfully traverse the Office's interpretation that no 
description of how methods are dependent or independent of a transport layer is given. It is 
respectfully submitted that one of ordinary skill in the art is well aware of the types of transport 
layers as well as the tasks and methods that are transport layer dependent and independent. 
Notwithstanding the knowledge of those skilled in the art, the specification provides adequate 
description of methods and tasks that are dependent or independent of the transport layer type 
in the specification, as originally filed. For instance, on page 10, lines 8-10, the Applicants 
provide: 

These implementations intermix transport-dependent tasks, such as IP 
address management, with transport-independent elements, such as packet 
decoders and encoders . [Emphasis added.] 

On page 11, lines 9-15, the specification further provides: 

. . .The transport-independent tasks module 500 includes the truly 
transport-independent tasks utilized during RTP streaming. For example, 
these transport-independent tasks can include packetization. depacketization, 
session management, and other transport-independent tasks as will be 
apparent to those skilled in the art . 
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The RTP connector 502 includes the transport-dependent tasks utilized 
during RTP streaming via the transport layer 504. These transport-dependent 
tasks can include transmission tasks, data receiving tasks, and other transport- 
dependent tasks as will be apparent to those skilled in the art . [Emphasis 
added.] 

On Page 17, lines 1 1-13, the specification also provides: 

The transport-independent tasks module 500 includes the truly transport- 
independent tasks utilized during RTP streaming. For example, these transport- 
independent tasks can include packetization, depacketization. session 
management . [Emphasis added.] 

The Applicants further traverse the Office's interpretation that the specification is silent 
as to what constitutes a "type" to be converted. The Applicants respectfully submit that one of 
ordinary skill in the art is well aware of what constitutes a transport layer type. Furthermore, 
the Applicants respectfully submit that the specification provides adequate description of what 
constitutes the "type" of a transport layer in numerous excerpts. For instance, on page 8, line 6, 
the specification provides that the RTP connector of the embodiments of the present invention 
allows the RTP stack to be easily adapted to any type of transport layer. On page 8, line 16, the 
Applicants have further provided that the transport protocol can vary. Furthermore, on page 
10, lines 11-13, the specification provides: 

However, the embodiments of the present invention provide a transport- 
independent RTP stack 404, which can be easily adapted to any type of 
transport layer , such as ATM or IP transport layers . [Emphasis added.] 

However, to overcome the Office's rejections, the Applicants have amended independent 
claims 1, 8, and 13, to recite a first underlying transport layer having a first protocol type, a 
second transport layer having a different protocol type (as defined in independent claims 1 and 
13), and underlying transport layers each having a different protocol type (as defined in 
independent claim 8). 

Furthermore, to overcome the Office' rejection that the specification fails to describe 
any methods present in the transport-independent tasks module, the Applicants have amended 
independent claim 1. As amended, independent claim 1 recites that the transport-independent 
tasks module is configured to perform tasks that are independent of the first underlying 
transport layer having the first transport layer type. Support for the amendments can be found 
through out the specification. 
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In view of the clarifying amendments, the Applicants respectfully request that rejection 
of the claims 1-20 under 35 U.S.C. § 1 12, first paragraph be withdrawn. 

Rejections under 35 U.S.C. § 112, Second Paragraph : 

The Office has rejected independent claims 1, 8, and 13 under 35 U.S.C. § 112, second 
paragraph as being indefinite for failing to particularly point out and distinctly claim the subject 
matter which the Applicants regard as the invention. The Office has specifically stated that it is 
unclear whether the connector module is modified or the connector module is not modified. 
The Applicants have amended claims 1 and 8 so as to recite that a new connector module is 
configured to be generated. Therefore, in view of the clarifying amendment, the Applicants 
respectfully request that rejection of the claims 1, 8, and 19, and 8, 10, and 20 under 35 U.S.C. § 
112, second paragraph be withdrawn. 

Rejections under 35 U.S.C. § 103 : 

The Office has rejected claims 1-20 under 35 U.S.C. § 103(a) as being anticipated by 
RFC 1889-RTP: A Transport Protocol for Real-Time Applications, January 1996 (hereinafter 
RFC 1889) in view of the United States Patent No. 6,175,789 to Beckert et al. (Beckert). It is 
respectfully submitted that the combination of the cited prior art fails to raise a prima facie case 
of obviousness against the subject matter defined in the claimed invention for several reasons. 

For instance, if RFC 1889 and Beckert were combinable (a proposition with which the 
Applicants disagree), the combination of the two references would not have disclosed, 
suggested, or taught a connector module or a new connector module of the claimed invention. 
Nor would the resulting combination have disclosed, taught, or suggested a connector module 
that includes methods dependent of the first underlying transport layer and in communication 
with a transport-independent module, and a new connector module generated to adapt the RTP 
stack to a second underlying module having a different transport layer type. 

Citing to Section 10 and the translator of Section 2 of RFC 1889, the Office has 
interpreted that the cited combination teaches the claimed invention, as defined in independent 
claims 1, 8, and 13. In the Office Action, the Office has interpreted that the translator taught in 
RFC 1889 discloses, teaches, or suggests the connector module of the claimed invention. The 
Applicants respectfully traverse the Office's interpretation as the description of the translators, 
as provided in Section 7 of RFC 1889 entitled "RTP Translators and Mixers," does not support 
the Office's interpretation. Rather, the description and functionality of the translator taught in 
RFC 1889 is contrary to the connector module of the claimed invention. 
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For instance, in pertinent parts, Section 7.1 of RFC 1889 provides: 

An RTP translator/mixer connects two or more transport-level "clouds". 
Typically, each cloud is defined by a common network and transport protocol 
(e.g., IP/UDP), multicast address or pair of unicast addresses, and transport 
level destination port.. . . 

In order to avoid creating a loop when a translator or mixer is installed, 
the following rules must be observed : 

Each of the clouds connected by translators and mixers participating in 
one RTP session either must be distinct from all the others in at least one of 
these parameters (protocol, address, port) , or must be isolated at the network 
level from the others. [Emphasis added.] 

Therefore, in accordance with section 7.1 of RFC 1889, so long as each participating cloud is 
defined by its own common network or protocol, the participating clouds use the same 
translator even though the participating clouds have different transport protocol types . That is, 
in the resulting combination, the same translator is used with both, the first transport layer 
having the first transport layer type and the second transport layer having a different transport 
layer type. Furthermore, there is no disclosure, teaching, or suggestion that a new connector 
module is generated. 

Additionally, rules that must be followed when installing a translator provided in RFC 
1889 in fact teach away from the claimed invention. According to the rule, a translator can be 
connected to participating clouds so long as each cloud is distinct from the other participating 
clouds in at least one of the parameters such as protocol, address, and port. That is, two clouds 
having distinct ports and different transport protocol layer types use the same translator. It is 
submitted that allowing multiple clouds having different types of transport protocols use the 
same translator teaches away from the claimed invention wherein a new connector module is 
generated for each different type of transport protocol type. 

Yet further, the translator disclosed in RFC 1889 cannot be the connector module of the 
claimed invention as the translator performs transport independent tasks, which in the claimed 
invention are configured to be performed by the transport-independent tasks module. It is 
submitted that in accordance with Section 7.1 of RFC 1889, the translators can " change the 
encoding of the data ." However, in accordance with the specification of the claimed invention, 
the encoding and decoding of the data, is a transport-independent task to be performed by the 
independent- tasks module of the claimed invention. See page 10, lines 8-10. 
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It must be noted that Beckert fails to cure the latter deficiencies in RFC 1889, as Beckert 
is only directed at computer systems for vehicles. It is submitted that providing applications 
for a vehicle computer systems is not in the field of, nor is reasonably pertinent, to a transport- 
independent RTP stack, as defined in the claimed invention. 

Additionally, the combination of the cited prior art fails to disclose, teach, or suggest all 
the features of the claimed invention, as defined in amended independent claims 1, 8, and 13. 
Among other features, the cited combination fails to disclose, teach, or suggest a transport- 
independent module , a connector module in communication with the transport-independent 
module that includes methods that are dependent on the first underlying transport layer , a new 
connector module that is generated so as to adap t the RTP stack to a second underlying 
transport layer having a different transport layer type , or a transport-independent tasks module 
that is configured to communicate with the new connector module in the same manner as the 
connector module. The cited combination further fails to disclose, teach, or suggest that a new 
RTP connector module is generated for each underlying transport layer that has a different 
transport layer type to adapt the RTP stack to the corresponding underlying transport layer. 

Accordingly, amended independent claims 1,8, and 13 are respectfully submitted to be 
patentable under 35 U.S.C. § 103(a) over the combination of the cited prior art. In a like 
manner, dependent claims 2-7, 9-12, and 14-20 each of which directly or indirectly depends 
from the applicable independent claim are submitted to be patentable under 35 U.S.C. § 103(a) 
over the combination of the cited prior art for at least the reasons set forth above regarding the 
independent claims 1,8, and 13. 

In view of the foregoing, the Applicants respectfully request reconsideration and 
reexamination of claims 1-20, and submit that all of the pending claims are in condition for 
allowance. Accordingly, a Notice of Allowance is respectfully requested. If the Examiner has 
any questions concerning the present Amendment, the Examiner is kindly requested to contact 
the undersigned at (408) 774-6913. If any additional fees are due in connection with filing this 
Amendment, the Commissioner is also authorized to charge Deposit Account No. 50-0805 
(Order No. SUNMP025). A duplicate copy of the transmittal is enclosed for this purpose. 



Respectfully submitted, 

Martine Penilla & GENCARELLA, LLP 



710 Lakeway Drive, Suite 200 
Sunnyvale, CA 94085 
Telephone (408) 774-6903 
Facsimile (408) 749-6901 
Customer No. 32291 
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